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U.S. Application No. 09/231,644, filed January 15, 1999 (Atty. Docket 
No. MLLTP001), commonly owned, is incorporated by reference herein for 
10 all purposes. 

Background of the Invention 

The present invention relates generally to computer software for filling 
out form documents over a computer network. More particularly, the present 
1 5 invention provides a method and system for sharing information among users 
for the purpose of automatically filling out fields in an electronic form 
document. 

The present invention describes a process for purchasing goods and 
services over an electronic computer network, namely the World Wide Web, 

20 for the purpose of Gift Shopping. Gift Shopping is defined as the act of 

buying a good or a service (the Product) for another person. Within the scope 
of the electronic computer network, Gift Shopping entails that the Gift Giver 
release personal information pertaining to the billing of the Product, and that 
the Gift Recipient release personal information pertaining to the shipping, 

25 size, and type of the Product. 

Thus, it is desirable to be able to share personal information with other 
users on a network. In such a system, a gift giver, for example, can access 
certain items of information, collectively referred to as a persona, which a gift 
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receiver has indicated can be accessed by others. A user can have a number of 
personas, each one used by a group of other users or one other user. 
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Summary of the Invention 

To achieve the foregoing, methods, apparatus, and computer-readable 
mediums are disclosed which provide an online shopper can share information 
5 with intended gift receivers. The information sharing can be used on 
numerous non-affiliated sites. That is, the sites at which the goods are 
purchased do not have to be within, for example, a portal's shopping mall or 
any type of "walled garden." Thus, the online gift giver can access 
information of gift receivers from a wide variety of non-associated and non- 

10 affiliated sites. While there are features similar to information sharing within 
restricted online shopping malls and networks of sites, information sharing 
outside these confines is presently unavailable. 

The present invention is a technique use to gather information from 
different sources to be used to automatically fill in online forms. The 

15 information is collected using a persona of an individual. A persona is created 
by filtering a larger set of raw data for that user so that only certain fields are 
allowed to be seen and used by others. An individual can have several 
personas, each assigned to a particular other individual, such as a family 
member or a friend. The individual allowing one of his personas to be shared 

20 is the information provider and the user requesting the information is the 

information requester. The information is taken from both the provider and 
requester, and used by a vendor in a form, filled out by the information 
requester. In one embodiment, the information requester is a "gift giver" and 
the provider is a "gift receiver." The gift giver is requesting shipping and 

25 other information from the gift receiver, who can grant one of his personas to 
the particular gift giver. The information, along with billing information from 
the gift giver, is used to fill out a vendor online form. 
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In one aspect of the invention a method of allowing an information 
requester, such as a gift giver, to access data from an information provider, 
such as a gift receiver, in order to complete an online merchant form is 
described. A filtered data set is created that contains data the information 
5 provider is willling to share with particular third-party users, including the 
information requester. An online merchant form is retrieved from a merchant 
or service provider site upon request by an information requester, the online 
merchant form having numerous fields. Data from the information requester 
is inserted into the appropriate fields in the form, such as billing information. 

10 Access to the filtered data set is granted by the information provider to the 
information requester. This enables data from the filtered data set to be 
inserted into the appropriate fields in the form, such as shipping information. 
The online form being filled out is from an online merchant or service 
provider that is not necessarily affiliated with other online merchants, such as 

15 being in an online shopping mall, a "walled garden," or network of sites 
associated with a portal. 
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Brief Description of the Drawings 

The invention will be better understood by reference to the following 
description taken in conjunction with the accompanying drawings in which: 

FIG. 1 A is a diagrammatical representation of a system for 
automatically filling in electronic form documents in accordance with one 
embodiment of the present invention. 

FIG. 1 B is a block diagram showing components of a server enabling 
the automatic insertion of data in to an electronic form on a remote computer 
in accordance with one embodiment of the present invention. 

FIG. 2 is a flow diagram of a process for automatically filling in an 
electronic form document in accordance with one embodiment of the present 
invention. 

FIGS. 3 A, 3B 5 and 3C are table diagrams showing the field names and 
format of registered user data in accordance with one embodiment of the 
present invention. 

FIG. 4 is a sequence diagram outlining a process of conducting 
purchasing gifts over a distributed network in accordance with one 
embodiment of the present invention. 

FIG. 5 is a flowchart describing a privacy negotiation for gathering 
information associated with purchasing gifts over a distributed network in 
accordance with one embodiment of the present invention. 

FIG. 6 is a block diagram showing the various parties and possible 
message passing between the parties in accordance with one embodiment of 
the present invention. 
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Detailed Description 

Reference will now be made in detail to a preferred embodiment of the 
invention. An example of the preferred embodiment is illustrated in the 
accompanying drawings. While the invention will be described in conjunction 
5 with a preferred embodiment, it will be understood that it is not intended to 
limit the invention to one preferred embodiment. To the contrary, it is 
intended to cover alternatives, modifications, and equivalents as may be 
included within the spirit and scope of the invention as defined by the 
appended claims. 

10 A method and system for automatically filling in electronic forms on a 

computer and not requiring a user to download or install any resident software 
on the computer is described in the various figures. As the presence of 
merchants and services increases on the Internet, electronic commerce or e- 
commerce will grow. More and more consumers will resort to the Internet, 

15 for example, to purchase goods and services for themselves or others (e.g., gift 
shopping). This will typically require the consumer/user to provide at least 
some data, either the users own or another individuals, to the merchant 
typically through filling out an electronic form having various fields, most 
commonly names, addresses, credit card numbers, phone numbers, etc. For 

20 consumers purchasing goods from numerous merchant sites and possibly 
using different computers (e.g. using a computer at work, using another 
computer at home, and yet another one while travelling), manually filling in 
these forms repeatedly can become tedious and inefficient. The present 
invention seeks to alleviate the burden of filling in electronic forms, while 

25 informing the consumer/user of privacy precautions taken by a particular 
merchant site, and not require the user to download any resident software. 
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Inherent in the latter feature is allowing the consumer to use the processes of 
the present invention from any computer connected to the network, the 
Internet in particular. 

The present invention uses a remote server or "privacy bank," a novel 
electronic resource that responds to requests for data by preparing and 
transmitting a specialized document in the form of a JavaScript. This 
JavaScript is formed dynamically by the privacy bank upon receipt of the 
request for data. The JavaScript created by the privacy bank is a "profile" or 
mapping between field names in a particular form the user needs to fill in at a 
particular merchant site (e.g. "www.fishermanstore.com" ) and standardized 
field names stored in the privacy bank server. Once the user's browser 
program is served this profile from privacy bank, most of the fields in the 
fishermanstore form are automatically filled in. In the described embodiment, 
the user becomes a member of the privacy bank resource by providing 
personal information, also referred to as the raw data, to privacy bank once. 
This raw data can be updated from time to time by the user if desired. In 
addition, several filtered raw data sets or "personas" can be created for use by 
others who may need to access the user's information. In another 
embodiment, the user can enter privacy rules or requirements once when 
initially becoming a member. The user does not need to download any 
software from privacy bank or any other resource. In the described 
embodiment, the merchant (e.g. The Fisherman Store) becomes an affiliate 
member of the privacy bank network by providing a sample document of its 
form or forms. Privacy bank can then build a mapping between fields in the 
merchant's form and the standardized fields in its own database. 

FIG. 1 A is a block diagram of a system for automatically filling out 
electronic form documents in accordance with one embodiment of the present 
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invention. A number of end-user computers are shown on the right side of the 
diagram. These computers can be client computers in a network with access 
to the Internet or be part of an intranet. In the described embodiment an end- 
user computer 102 is a stand-alone computer with access to the Internet and 
contains an Internet browser program, a browser window for which is shown 
at 104. In the center of the diagram is a number of Web servers. A particular 
Web server 1 06 is a server for a merchant Web site, such as 
www.fishermanstore.com to which users or consumers can visit to purchase 
goods online over the Internet. On the left side of the diagram is a specialized 
electronic resource referred to in the described embodiment as a privacy bank 
server computer 108, also connected to the Internet. 

The process of automatic electronic form completion begins with a 
user downloading the form from a Web site such as fishermanstore site. 
Returning to FIG. 1A, a user/consumer on computer 102 ("user 102") opens a 
browser window 1 04 in an Internet browser program such as Netscape 
Navigator or Internet Explorer, depicted by arrow 110. User 102 then goes to 
www, fi shermanstore . com shown by arrow 112 via the browser and decides to 
purchase goods. User 102 then downloads from the Web site contained on 
Web server 1 06 an electronic purchasing form that needs to be completed as 
depicted by arrow 114. A purchasing form 116, typically an HTML 
document, is returned and downloaded into and displayed in browser window 
104. At this juncture, user 102 would normally have to "manually" fill in 
each field in purchasing form 116. Much of this information is typically 
standard: name, address, phone number, payment method, user email address, 
etc. In accordance with one embodiment of the present invention, user 1 02 
can "click" on a privacy bank icon or button in form 1 1 6 and have the form 
automatically filled in. 
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As stated earlier, it is assumed in this discussion that 
www. fi shermanstore .com is registered with and thus an affiliate member of 
the privacy bank service assessable from privacy bank server 108. Being an 
affiliate member of the privacy bank service, purchasing form 1 1 6 contains a 
5 privacy bank icon or button 118. By clicking on privacy bank icon 1 1 8, user 
102 essentially completes a process for automatically filling in form 1 16 by 
transparently transmitting a completed form to the privacy bank service on 
server 108, depicted by an arrow 120. The information needed for filling in 
the form is transmitted to user 102 once form 1 16 (an HTML document) is 

10 parsed, which occurs when form 1 16 is downloaded. This process is 

described in greater detail in FIG. 4. User 102 informs privacy bank server 
1 08 of the identity of the user and of which Web site and which form on that 
Web site (if more than one) the user wishes to have filled in. This information 
is transmitted to privacy bank server 108, unbeknownst to user 102, when 

1 5 form 1 1 6 is downloaded. Techniques for accomplishing this are described 
below. Once privacy bank server 1 08 receives a request from registered user 
102 (by virtue of an external link in form 116 executed when the form is 
parsed by user 102), it begins preparing information needed to fill in form 116 
on user computer 102. In the described embodiment, the information sent to 

20 user computer 102 is a JavaScript program 124 referred to as a "profile." 
Explained briefly, this profile contains a mapping of privacy bank 
standardized fields and fields in purchasing form 1 16 and "raw," generally 
personal, data associated with user 102. The content of this profile and 
JavaScript program in general is described in greater detail in FIGS 7A and 

25 7B below. Once received by the browser program on user computer 102, the 
filled out purchasing form 1 16 is displayed to user 102 as depicted by arrow 
126. This occurs when user 102 presses or clicks on privacy bank icon 118. 
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The information needed to complete form 1 16 is already resident in the 
browser program. At this juncture, user 1 02 can decide whether to proceed 
with submitting the form (typically after filling out a few more fields such as 
which items to purchase, quantity, etc.) or declining to submit the form, 
5 perhaps after reviewing the fishermanstore's Web site privacy safeguards or 
for any other reason. 

FIG. 1 B is a block diagram showing components of a privacy bank 
server enabling the automatic filling in of electronic forms on a remote user 
computer. A privacy bank server, such as server 108 in FIG. 1A, contains 

10 several functional and storage components needed for compiling the data 
needed for filing in a form, such as form 116. Shown in FIG. IB are four 
major components of a privacy bank server in the described embodiment. 
These components and storage areas include a raw data profile storage area 
128, a form mapping storage area 130, a negotiation history module 132, and 

15 a shippable code constructor 134. Raw data profile storage area 128 contains 
sets of data relating to registered users of the privacy bank service, one set or 
profile shown in area 136. A registered user has a unique account number that 
can be used as an identifier and a password, shown in an area 138. The 
standard field names set by the privacy bank service, discussed in greater 

20 detail in FIGS. 8 A, 8B, and 8C, are paired with a user entered data string 
(such as first name or home street address), followed by a use-preference 
condition. This data is contained in an area 140. Another profile for another 
registered user is shown in an area 142. Each registered user has a similar raw 
data profile. 

25 Form mapping area 130 includes multiple form mappings, an example 

of which is shown in an area 144. Each electronic form that is registered with 
the privacy bank service by an online merchant or seller (/. e. an affiliate 
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member) has a form mapping. A privacy bank standard field name, as 
discussed below in FIGS- 3A 5 3B, and 3C, and as mentioned above in area 
140, is matched or mapped with a "non-standard" field name from the 
electronic form registered with the service. For example, a non-standard field 
5 name for a person's last name could be "Last Name," "Surname" or simply 
"Last." Different forms use different variations of names for this field and for 
other fields. This would be mapped against the privacy bank "standard" field 
name, which in the described embodiment, is "PersonName.Last." Also 
contained in area 146 is a practice-preference condition provided by the online 

10 merchant or seller when registering the form. As with the use-preference 

condition in area 140, this condition is used by negotiation history module 150 
and shippable code constructor 134, and is discussed in greater detail below in 
FIG. 7. Another mapping 148 having the same format for another registered 
form follows area 144. 

15 Negotiation history module 132 is used to determine which fields in 

the electronic form will be automatically filled in by the privacy bank server. 
A process associated with negotiation history module 132 is described in 
greater detail in FIG. 7. Module 132 includes multiple negotiation objects, an 
example of which is shown in an area 1 50. In the described embodiment, each 

20 negotiation object corresponds to one "non-standard" field in the form. 

Described briefly, negotiation object 150 contains information as to whether 
the field in the form should be filled in based on privacy and use preferences 
set by the user (as conveyed in use-preference condition in area 140) and 
compared to intended practices (as conveyed by practice-preference condition 

25 in area 146). This comparison is performed in the negotiation history module, 
which includes a negotiator or comparator for comparing these conditions. 
Specific conditions in the described embodiment are described below. If it is 
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determined that the non-standard field in the form will be filled in, a data 

string, shown in area 140, will be included in negotiation object 150. 

Shippable code constructor 1 34 accesses component 132 and storage areas 

128 and 130, to derive a software module to be transmitted to a user computer. 
5 In the described embodiment, the software module is a JavaScript program 

which is transmitted to and executed by a browser in the user computer, 

thereby inserting the data strings into the form fields. 

FIG. 2 is a flow diagram of a process for automatically filling in 

electronic forms in a computer network in accordance with one embodiment 
ijg 1 0 of the present invention. The process described below can be performed in a 

pj configuration of servers and computers as described in FIG. 1 A above. At a 

j= step 202 an online user/consumer desiring to purchase certain goods on the 

Internet downloads an electronic form for making a purchase into the user's 
;L browser program. At step 204 the browser parses the electronic form content, 

r* 15 typically an HTML document, to identify all external links. As is 

y commonplace for Web pages, the HTML contains links to other external Web 

s J 

O sites from which content or other types of data is retrieved. In many instances, 

a Web page is a composite of different components from various sites 
embedded in a core HTML document. An example is an external link to an ad 

20 server to retrieve a banner ad component of a core HTML document. In this 
case, the electronic form can be seen as a core HTML document. This parsing 
is done automatically by the browser and is a well known feature. 

At step 206 the browser identifies an external link to the privacy bank 
server. In the described embodiment, this link will necessarily be present 

25 since the Web site is an affiliated site of the privacy bank service network of 
registered sites. A description of what "registered" implies in this context is 
described in greater detail below. At step 208, the browser executes the 
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external link to connect the browser to the privacy bank server. The external 
link is referred to in the described embodiment as a shippable code link to the 
privacy bank server. The shippable code in this context is a JavaScript 
program that is transmitted from the privacy bank server to the user computer 
and browser. This shippable code enables the electronic form to be filled in 
automatically in a process that is described in greater detail below. At step 
210, once the privacy bank server has been contacted via the shippable code 
link in the electronic form, the privacy bank server determines whether the 
user computer or browser has a valid state identifier, referred to as a "cookie", 
previously assigned to it by the privacy bank server. A cookie is an identifier 
assigned by a Web site, whether a Web server or a server such as the privacy 
bank server, to a user/visitor when the user visits the Web site for the first 
time in a given session (the time from which a user logs onto the Web and the 
time he or she exits the Web by exiting the browser). The cookie, assigned by 
a Web site, belongs to a particular user. In the described embodiment, the 
user keeps this cookie during its session (a temporary cookie) and if the user 
goes back to that Web site during that session, it shows the Web site that 
cookie from which the Web site can identify the user and retrieve 
characteristics of that user from its data repository. As is known in the art of 
Internet application programming, cookies can also be permanent in that they 
subsist with a user after the user has logged off the browser and can be used 
again in a new session. The concept and implementation of cookies 
themselves are well known in the field of Internet and, more generally, 
computer network programming. 

If the privacy bank server determines that the user computer or 
browser does not have a valid cookie, it implies that the user has not yet 
logged into the privacy bank service. If so, control goes to step 212 where the 
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privacy bank server retrieves a login sequence code. This code will trigger a 
login sequence and enable the user to log in to or register with the privacy 
bank service at a later step in the process, as described in greater detail below. 
At step 214, the privacy bank server forms a completed package of shippable 
5 code containing the retrieved login sequence code, such that the login 
sequence will be triggered at a later step in the process. At step 222, the 
browser retrieves this completed package of shippable code from the privacy 
bank server. The shippable code is then stored in the browser residing on the 
user's computer, and is executable upon a user trigger, which is described in 

10 greater detail below. 

If the privacy bank server determines that the user/browser making 
contact by downloading the electronic form and executing the external link 
has a valid cookie, control goes to step 216 where the privacy bank server gets 
and reads the user's cookie. In this context, having a valid cookie indicates 

1 5 that the user has already gone through the login sequence recently, for 

example during the existing Internet session, and thus it is not necessary for 
the user to go through the login sequence again. By reading the user's cookie, 
the privacy bank server can determine who the user is and thus can retrieve the 
user's raw data stored by privacy bank. The contents and format of this raw 

20 personal data is described in greater detail in FIGS. 8A, 8B, and 8C below. At 
step 218, the privacy bank server retrieves the user data for the user identified 
by the valid cookie. The privacy bank server couples this user data and an 
identifier, such as a URL (uniform resource locator), to determine how the 
electronic form document should be filled. At step 220, the privacy bank 

25 server forms a completed package of shippable code (item 124 in FIG. 1 A) 

containing the user data that will be used to fill out the form document. In the 
described embodiment, this shippable code, referred to as a profile, is in the 
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form of a JavaScript program. This shippable code is formed from 
information in the privacy bank memory that will enable the form document 
to be filled out automatically at a step later in the process. At step 222 the 
browser receives the shippable code, or profile, from the privacy bank server, 
5 and now has access to it on the user computer, if desired by the user. This 
profile is stored in the browser residing on the user's computer, and is 
executable upon a user trigger. 

Assuming the user wants to have the electronic form automatically 
filled out using privacy bank, he or she executes a user trigger. In the 
'O 10 described embodiment, this trigger occurs when the user clicks on an 

fU "autofilP' button contained in the form and associated with privacy bank at 

c . = 

=p step 224. By clicking on the autofill button, the user allows the browser to 

a 

S execute the shippable code or profile stored thereon. At step 226, the 

Q shippable code determines whether it contains user data which would permit it 

y± 15 to fill out the form document. If user data is contained within the shippable 

5 code residing on the browser, control goes to step 234 where the browser 

™ : utilizes the shippable code and user data to fill out the electronic form 

document. Of course, user data being present in the shippable code is 
dependent upon the browser having a pre-existing valid cookie when the form 
20 document was initially retrieved, as described above. 

If, however, user data is not contained within the shippable code 
residing on the browser, control goes to step 228 where the login sequence is 
initiated in order to identify the presently unknown user. The shippable code 
utilized by the browser in this step contains the login sequence code, which is 
25 a result of the browser not having a pre-existing valid cookie when the form 

document was initially retrieved, as described above. Once the user completes 
the login sequence at step 228, the privacy bank server assigns a cookie to the 
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user/browser thereby enabling it to recognize the user and messages from the 
user's browser in subsequent transactions. At step 230, the privacy bank 
server retrieves the user data for the identified user, couples this user data and 
an identifier, such as a URL (uniform resource locator), to determine how the 
5 electronic form document should be filled, and forms a completed package of 
shippable code containing the user data that will be used to fill out the form 
document. This step is substantially similar to steps 218 and 220, as described 
above. At step 228, the browser receives the shippable code, or profile, from 
w the privacy bank server, and now has access to it on the user computer. This 

*B 1 0 shippable code now contains user data that allows the form document to be 

TU filled out automatically. At this stage, control proceeds to step 234, where the 

= it 

browser utilizes the shippable code and user data to fill out the electronic form 
O document. Further input from the user, such as re-clicking on the "autofill" 

p button, is not required. In other words, once the user properly completes the 

ill 15 login sequence, the form is then filled out automatically, and it is not 

necessary for the user to click on the "autofill" button again. 
^ At step 236, the user visually examines the filled out form and the 

privacy features offered by the Web site and decides whether the form is 
acceptable. If the user finds that the form needs further adjustment, the user 
20 adjusts the document at step 238. This may be done manually, or through any 
supplemental automated process, such as a client-based macro. This can 
involve filling in fields that could not be filled in by the profile sent by the 
privacy bank server (in other words, fields that could not be filled out from the 
raw data). Such fields can include, for example, which items being purchased 
25 and the quantity of items. It can also include updated personal information 
such as a new address or credit card number. In this case, the user simply 
types over the information already in the fields. Control then returns to step 
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236, which is satisfied presumably after going through step 238 once. At step 
240 the browser submits the filled out electronic form eventually sending it to 
the merchant's Web server once the user clicks on a Submit form button in the 
browser window.. In the described embodiment, the filled out form is first 
5 sent to the privacy bank server unbeknownst to the user or at least transparent 
to the user. The completed form is received and examined by the privacy 
bank server which updates its raw data repository to reflect any changes the 
user may have made to his or her personal information. The privacy bank 
server then posts a message back to the user computer (according to HTTP 

1 0 protocol the server must send a message back to the user computer when it 
receives an HTML document from it). In the described embodiment, the 
message it sends back or posts to the user's browser is similar to a "Click Here 
To Continue" type screen to the user. Hidden behind this message is the 
completed form that was sent to the privacy bank server. Presumably, the user 

1 5 will click to continue and by doing so transmits the hidden completed form to 
the merchant's Web server. In other preferred embodiments, the completed 
form is sent to both the privacy bank server and the merchant's Web server at 
the same time. In yet another preferred embodiment, the completed form is 
posted automatically from the privacy bank server directly to the merchant's 

20 site without any additional input from the user. At this stage the automatic 
form filling process is complete. 

FIGS. 3A, 3B, and 3C are high-level table diagrams showing how 
fields containing the raw data and preferences for a user are organized on the 
privacy bank server in accordance with one embodiment of the present 

25 invention. A top-level User table 302 has four columns: User 304, Category 
306, Type 308, and Short display name 310. User Table 302 has four areas of 
data under column User 304 represented by four rows: Home 312, Work 314, 




Attorney Docket No. MLLTP006 



17 



Patent 



# 



Billing 316, and Shipping 318. In the described embodiment, the user is 
presented with these four areas of data when registering with the privacy bank 
service and enters information by going through each of these data areas. 
Skipping Category 306 for the moment, column Type 308 takes the raw data 
5 tree down one level from the top level represented by table 302. For example, 
the Type for data area Home 3 12 is Info. This performs as a pointer or link to 
an Info table 320. The first column 322 of table 320 is labeled Info but the 
other three columns are the same as shown in table 302; that is, Category 306, 
Type 308, and Short display name 310. 

10 At table 320, the user begins entering data that will be used for her 

home information and for Shipping since data area 318 for Shipping in table 
302 also has an Info in its Type column 308. A Name row 322 has in its Type 
column 308 a reference to yet another table PersonName, shown as table 324. 
Similar to table 302 and 320, PersonName table 324 has a first column labeled 

1 5 PersonName and the same three columns as the other tables. All five data 

areas in PersonName table 324: Prefix, First, Middle, Last, and Suffix have as 
a Type a primitive type referred to as Text in the described embodiment. Text 
represents a data string that is the actual data item stored in the privacy bank 
server. By examining the Type column 308 of each of the data areas, a user 

20 enters all the raw personal data. An actual data item is entered at each Type 
box containing Text, indicating a primitive type, or a leaf node when viewed 
as a tree structure. If the Type column does not contain "Text," another table 
exists that refines the data area further. 

To follow another example, under the data area Billing 316 shown in 

25 table 302, its Type 308 indicates Billlnfo and not Text. A table Billlnfo has 
six further data areas, none of which have a Text Type, so no actual data 
values can be found at this level. Taking the CreditCard data area as an 
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example, its Type indicates "CreditCard." Table CreditCard, shown in FIG. 
3C, has four data areas: Type, Number, ExpMonth, and Exp Year, all of which 
are of Type Text, which contain actual data values. 

Short display name column 310 contains a string that is displayed to 
5 the user through a user registration graphical user interface of the described 
embodiment. The user follows the data tree via a user interface using the 
Short display name strings as field names or guides to entering the data. The 
data areas that have primitive Types, which in the described embodiment is 
Text, are the privacy bank field names that are mapped with the legacy field 
nfl 10 names in the electronic forms registered with the service. In the described 

£ s=3 
S J | 

pj embodiment, the privacy bank names include (in abbreviated form): 



PersonName.Prefix 
PersonName.First 
15 PersonName.Last 
PersonName. Suffix 



20 Internet.Email 

Internet.HomePage 

CreditCard.Type 
CreditCard.Number 
25 CreditCard.ExpMonth 
CreditCard.ExpYear 

Category column 306 is related to privacy settings set by the user and 

are tied to the preferences set by a user and defined in terms of the conditions 

30 as described above. The conditions or use thresholds in the described 

embodiment are marketing (targeted), system administration, personalization, 
research and development, and completion of activity (i.e. ordering). The 
Categories available in the described embodiment and as shown in the tables 
of FIGS. 3 A, 3B, and 3C, are Physical Contact Information, Online Contact 

35 Information, Demographic Data, and Financial Data. The relationship 




Address. Street 1 PhoneNum. AreaCode 

Address. Street2 PhoneNum.Number 

Address . City PhoneNum . Extension 
Address . StatePro v 
Address.PostalCode 
Address . Country 

Employment.Employer 
Employment.Department 
Employment.JobTitle 
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between the Categories and the conditions of the described embodiment can 
be described as a table five-row, four-column table (a 20 cell table) where 
each condition is one row in the table and each Category is one column in the 
table. 

5 The present invention is an extension to a Form AutoFill Server using 

Personal Information sharing between Individuals to fill in electronic forms 
that are a part of the Form AutoFill and/or Gift Shopping service (the 
Service). The Form AutoFill Server is used to dispatch JavaScript code to the 
Web Browser, which enables the form to be filled. The Form AutoFill Server 

E s 
tssss- 

jtj 10 is a use of a Light Code Server, which serves Shippable Code Segments that 

|4 are executed on the Web Browser's machine. By allowing Individuals to share 

s P their information with other Individuals, the Form AutoFill Server can provide 

(3 data elements from two or more Individuals during a Privacy Negotiation (see 

O Privacy Negotiation) . 

W 

M» 15 The essence of Gift Shopping is that more than one Persona is used to 

q fill a form. A Persona is defined as a data repository containing an 

~ Individual's personal information along with the privacy preferences that 

indicate how the Individual wants his or her data treated. Users of the Service 
may have multiple Personae as well as permission to use parts of other 
20 Individuals' Personae. There are two kinds of Gift Shopping that need to be 
covered. The first is Gift Shopping for people who are not necessarily 
subscribers/members of the Service. The second is Gift Shopping for people 
who are subscribers/members of the Service. In the latter case, we have to 
cover the mechanism for releasing permission to use a Persona of an 
25 Individual by another Individual for Gift Shopping purposes. 

FIG. 4 is a flow diagram of a process of an Individual (Gift Giver), 
who is Gift Shopping online and purchases a product from a Product Vendor 
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that subscribes to the privacy bank service. They would like to buy a Product 
401 that the Vendor is offering through an online form. The Gift Giver 
commands the browser to request a form from the Vendor 402. The Vendor 
returns the document to the browser 403, which in turn displays the form to 
the Gift Giver 404. The Gift Giver clicks the 'Gift Shop' button 405, which is 
embedded in the HTML form at the Vendor's web site. The 'Gift Shop' 
button is the trigger that requests the Gift Recipient Selection form from the 
Service 406. Since the intended Recipient is not a member of the Service, the 
Gift Giver may elect to create a new Persona or use a Persona that they have 
created in the past for Gift Shopping 409. The Gift Giver must fill in shipping 
information and any information related to the Product for a new Persona. 
During the selection of the Gift Recipient, a session parameter is set to 
identify which Persona to use for a Gift Recipient 410 when the Privacy 
Negotiation is to be conducted. After completing the Recipient creation, the 
browser is sent a document 411 that automatically requests the HTML form 
from the Vendor 412. The HTML form is returned to the browser 413, which 
again displays the form to the Gift Giver 414. Each time the form is loaded, it 
makes a request to the Form AutoFill Server, which conducts a Privacy 
Negotiation (see Privacy Negotiation) between electronic agents representing 
the Vendor, the Gift Giver, and the Gift Recipient if the Gift Giver is logged 
into the Service. JavaScript code is returned to the browser and executed there 
415, filling the form with the results from the Privacy Negotiation. The Gift 
Giver then submits the form by clicking a 'Submit' button 416, which 
commands the browser to post the submission to the Service 417. After 
processing the submission, the browser receives a document 418, which 
commands the browser to submit the information to the Vendor's Web Server 
419. 
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A Gift Giver, who is Gift Shopping online, visits a Product Vendor 
that subscribes to the Service. The Gift Giver would like to buy a Product the 
Vendor is offering 401 . The browser requests an HTML form from the 
Vendor 402. The HTML form is returned to the browser 403, which is then 
5 displayed to the Gift Giver 404. The Gift Giver clicks the 4 Gift Shop' button 
405, which makes the request for the Gift Recipient Selection form from the 
Service 406. The 'Gift Shop 5 button is embedded in the HTML form at the 
Vendor's web site. The Gift Recipient Selection Page is returned to browser 
407, which is displayed to the Gift Giver 408. The Gift Giver may select a 

10 Recipient's Persona 409 that has been made accessible to the Gift Giver by the 
Gift Recipient (see Sharing Personae). The browser posts the Gift Recipient 
Selection to the Service 410. The browser is sent a document 41 1 that 
automatically requests the HTML form from the Vendor 412. The HTML 
form is returned to the browser 413, which again displays the form to the Gift 

15 Giver 414. Each time the form is loaded, it makes a request to the Service, 
which conducts a Privacy Negotiation (see Privacy Negotiation) between 
electronic agents representing the Vendor, the Gift Giver, and the Gift 
Recipient if the Gift Giver is logged into the Service. JavaScript code is 
returned to the browser and executed there 415, filling the form with the 

20 results from the Privacy Negotiation. The Gift Giver then submits the form by 
clicking a 'Submit 5 button 416, which commands the browser to post the 
submission to the Service 417. After processing the submission, the browser 
receives a document 418, which commands the browser to submit the 
information to the Vendor's Web Server 419. 

25 A Privacy Negotiation is the process of determining if a Vendor's 

stated Privacy Practices meet the requirements of an Individual's Privacy 
Preferences. A standard Privacy Negotiation is conducted between a single 
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Information Buyer (Vendor's agent) and a single Information Seller 
(Individual's agent). In the case of Gift Shopping the Information Seller is a 
composite of Personae, which are separate Information Sellers. This 
composite Persona is achieved through a networked solution. A Message 
Router is used to direct BIDs from the Information Buyer to the Information 
Seller that they apply to. Each Information Seller connected to the Router has 
a mask assigned which controls which BIDs route to them based on what part 
of the Service's personal information data schema is being requested. This is 
the same model as an electronic computer network router, which routes data 
packets to a given machine based on the routing table of the router. Using this 
model allows for the individual Personae (Information Sellers) to respond to a 
BID based on the Privacy Preferences stored in the Persona that the BID gets 
routed to. 

FIG. 5 is a flow diagram of a Privacy Negotiation that begins by 
requesting if the Information Buyer 501, which is an agent for the Vendor in 
the current model, has any more BIDs. If Yes, the Privacy Negotiation records 
the BID in its transaction history and forwards it to the Information Seller 502, 
which is a Message Router in the case of Gift Shopping. The Message Router 
receives the BID 503, and determines if it is intended for the Gift Giver's 
Information Seller or the Gift Recipient's Information Seller based on the 
mappings that define Gift Shopping 504. In the instance there is no gift 
shopping, control from 503 goes straight to 508 where it is determined if the 
BID meets certain privacy preferences of the information seller. Returning to 
step 504, if the BID is intended for the Gift Giver's Information Seller, it 
receives the BID 505. If the BID is intended for the Gift Recipient's 
Information Seller, it receives the BID 506. The BID is considered by the 
Information Seller that receives it 507. The Information Seller determines if 
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the BID meets the Privacy Preferences stored inside of it 508. If the BID is 
accepted, an ACCEPT message is sent as the reply 509. If the BID is rejected, 
a DENY message is sent as the reply 5 1 0. The Message router receives the 
response from the Information Seller it sent the BID to and forwards the 
5 response to the Privacy Negotiation 511. The Privacy Negotiation records the 
response in its transaction history in step 512 and returns to step 501 . If the 
Information Buyer has no more BIDs, the Privacy Negotiation is complete. 

In order for an Individual (Gift Giver) to use another Individual's (Gift 
^ Recipient) Persona, the Gift Recipient must explicitly grant access to the Gift 

;S 10 Giver. A Gift Giver may request access from a Gift Recipient, after which the 

jU Recipient may grant or deny access. A Gift Recipient may also add a Gift 

Giver without receiving a request. Once access is granted, the Gift Recipient is 
O added to the Gift Giver's list of Gift Recipients for use while Gift Shopping. 

O FIG* 6 is a block diagram showing the various parties and possible 

- - 1 

h& 15 message passing between the parties in accordance with one embodiment of 

£3 the present invention. The parties shown are the vendor or store merchant, a 

" gift giver (information requester) and gift recipient (information granter). In 

between the parties is a message router that is part of the privacy bank server. 
A vendor sends out a BIDS which is routed by the message router. The BIDS 
20 billing portion is sent to the gift giver and the BIDS shipping information is 
sent to the gift receiver. Both the gift receiver and gift giver reply with either 
an Accept or Deny to the BIDS request. The Accept or Deny messages from 
the parties are then sent to the Vendor. If the gift receiver sends a Deny 
message, he is indicating that he does not want to share his information with 
25 the gift giver. Although it is possible for the gift giver to deny the BIDS 
shipping request, it is unlikely since he is typically the one requesting the 
information from the gift receiver. Once the vendor receives the messages, it 
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acts accordingly by either shipping out the goods or sending a message to the 
gift giver that the BIDS shipping information request was denied. 

Although the foregoing invention has been described in some detail for 
purposes of clarity of understanding, it will be apparent that certain changes 
and modifications may be practiced within the scope of the appended claims. 
Furthermore, it should be noted that there are alternative ways of 
implementing both the process and apparatus of the present invention. 
Accordingly, the present embodiments are to be considered as illustrative and 
not restrictive, and the invention is not to be limited to the details given 
herein, but may be modified within the scope and equivalents of the appended 
claims. 
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